Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DofHandler with any <: AbstractGrid #379

Merged
merged 14 commits into from
Apr 22, 2022
Merged

DofHandler with any <: AbstractGrid #379

merged 14 commits into from
Apr 22, 2022

Conversation

koehlerson
Copy link
Member

This PR is in the same spirit of #309 and not such a crowded catastrophe as #307

I added cellnodes! and cellcoords! dispatches for AbstractGrid that only call the interface function of <:AbstractGrid. I noticed that this is needed when we did the first <:AbstractGrid prototype. I'm not sure if these definitions should better live in grid.jl. They assume a concrete homogeneous cells vector right now, since they are only called by DofHandler.

I'd like to do a follow up PR such that a CellIterator also can handle any <:AbstractGrid. Then, we would only need consistent usage of the interface functions and everything should work ootb for properly subtyped grids

@codecov-commenter
Copy link

codecov-commenter commented Oct 6, 2021

Codecov Report

Merging #379 (5f5d25b) into master (9d40af5) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #379   +/-   ##
=======================================
  Coverage   91.50%   91.50%           
=======================================
  Files          22       22           
  Lines        3259     3259           
=======================================
  Hits         2982     2982           
  Misses        277      277           
Impacted Files Coverage Δ
src/Dofs/DofHandler.jl 83.51% <100.00%> (ø)
src/iterators.jl 96.92% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9d40af5...5f5d25b. Read the comment docs.

@koehlerson
Copy link
Member Author

grafik

@koehlerson
Copy link
Member Author

grafik

@koehlerson
Copy link
Member Author

koehlerson commented Jan 7, 2022

Comparing heat equation on master vs this branch on my laptop (subject to a plethora of fluctuations) in order to see if there is a significant performance drawback. Note this is not intended as performance benchmark but rather as a rough estimate if something was utterly needed w.r.t. type instability

PR

200 x 200 elements
julia> @time include("docs/src/examples/heat_equation.jl")
  1.148711 seconds (187.30 k allocations: 113.092 MiB, 2.27% gc time, 19.11% compilation time)
 
500 x 500 elements
julia> @time include("docs/src/examples/heat_equation.jl")
  6.478253 seconds (400.90 k allocations: 702.862 MiB, 4.93% gc time, 3.64% compilation time)

Master

200 x 200 elements
julia> @time include("docs/src/examples/heat_equation.jl")
 1.152864 seconds (201.76 k allocations: 113.971 MiB, 11.94% gc time, 21.89% compilation time)
 
500 x 500 elements
julia> @time include("docs/src/examples/heat_equation.jl")
 6.244453 seconds (401.77 k allocations: 702.985 MiB, 3.77% gc time, 3.58% compilation time)

@koehlerson
Copy link
Member Author

ping @fredrikekre

Copy link
Member

@fredrikekre fredrikekre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rebase?

Comment on lines 291 to 307

function cellnodes!(global_nodes::Vector{Int}, grid::AbstractGrid{dim}, i::Int) where {dim}
C = getcelltype(grid)
@assert length(global_nodes) == nnodes(C)
for j in 1:nnodes(C)
global_nodes[j] = getcells(grid, i).nodes[j] ##TODO getnodes(::AbstractCell); only vertices(::AbstractCell) available
end
return global_nodes
end

function cellcoords!(global_coords::Vector{Vec{dim,T}}, grid::AbstractGrid{dim}, i::Int) where {dim,T}
C = getcelltype(grid)
@assert length(global_coords) == nnodes(C)
global_coords .= getcoordinates(grid, i)
return global_coords
end

Copy link
Member

@fredrikekre fredrikekre Apr 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what we really need is:

# shared implementation for all grids
function cellcoords!(global_coords::Vector{Vec{dim,T}}, grid::AbstractGrid, cell::C) where {dim,C<:Ferrite.AbstractCell,T}
nodes = cell.nodes
N = length(nodes)
@assert length(global_coords) == N
for j in 1:N
global_coords[j] = grid.nodes[nodes[j]].x
end
return global_coords
end
function cellcoords!(global_coords::Vector{Vec{dim,T}}, grid::AbstractGrid, i) where {dim,T}
cell = getcells(grid, i)
cellcoords!(global_coords, grid, cell)
end
from Kim's #445

It's supposed to handle the information for the reinit! which needs the actual coords for any grid. The functionality can be recovered by using the already defined functions on AbstractGrid, so getcoordinates etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can either delete the functions completely and wait for Kim's PR or we take the ones from Kim's PR with the slight improvement suggestion I made over there

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We almost have this since #425 though (see Fredriks comment above). Why not just make the changes to that one? Allowing AbstractGrid in the function signature and using getcells + getnodes should literally have no impact on using the function with the regular Grid.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I think I misunderstood the comment in the beginning. I changed in the latest commit the functions to work for any <: AbstractGrid (I hope you meant this @kimauth, otherwise I'll revert it) I had to use the getcoordinates dispatch for the Node type as an abstraction in between, otherwise grids always need to use Node as their node type. In the test example I only used a NTuple{dim}, but we can also just assume that Node is always used, if you prefer this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like what I meant.
I think assuming that a node always has a field x for the coordinate is not too much of a stretch - but considering that we have getcoordinates(node) it's good to use I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants